1. Field of the Invention
The invention relates to communication networks and in particular to authentication and key agreement protocols in such networks.
2. Description of the Related Art
Authentication and Key Agreement (AKA) protocols are widely used in wired and wireless environments to provide key material and proof of the identity between two connected entities. A typical example is a wireless subscriber accessing a Cellular Network who is authenticated towards an authentication server in the network.
Different entities or devices are involved in an AKA procedure.
A terminal HT which hosts a personal token (e.g. a mobile phone) and an authentication server (AS) communicate together. The personal token and a secure server store a same secret key K, also known as the master key.
In the usual AKA protocol (e.g. for implementing a secure data transfer), both the authentication server and the hosting terminal HT are able to use keys which are derived from a master key i.e. an integrity key Ik and a ciphering key Ck. Such keys Ik and Ck are derived from a master key which is shared by a secure server on one hand and the personal token on the other hand.
In other circumstances, i.e. a special AKA procedure, both the hosting terminal may be deprived from use of the Integrity key Ik and the ciphering key Ck, i.e. these derived keys be considered as sensitive data which must not be disclosed to the hosting terminal.
The procedure for performing a usual AKA procedure will now be described in reference to FIG. 1.
Typically, a secure server SS chooses a randomized array RAND. Using RAND with an algorithm called AKAAIg and the secret key K which is shared only by the secure server SS and the personal token, the secure server SS produces an authentication vector (AV).
The authentication vector AV is composed at least of the following components: the initial RAND, a result value (RES), some derived key material (DKM) i.e. typically the derived keys Ik and Ck, and a message authentication code (MAC). The authentication vector AV is then delivered to the authentication sever AS.
The authentication server AS sends the values RAND, MAC values and possibly other data to the hosting terminal HT. The hosting terminal then sends them to the personal token SE.
The personal token SE runs AKAAIg algorithm using the stored secret key K and the received parameters (at least RAND, MAC).
The personal token SE re-computes a MACT on the basis of the shared secret key K, and on the basis of the received RAND.
The personal token SE then compares the re-computed MACT value with the received MAC value (is MAC=MACT ?) in order to perform some integrity check and possibly an authentication procedure of the authentication server.
Then the personal token SE computes RES.
The hosting terminal sends RES to the authentication server so that the personal token becomes authenticated by the server. At the end, the authentication server AS authenticates the personal token by comparing the RES received from the hosting terminal with the XRED value received from the secure server SS.
The personal token SE also computes the derived keys Ik and Ck and sends them together with RES to the hosting terminal. The hosting terminal uses the derived keys to perform any further security operation towards the AS.
An example of this basic authentication AKA procedure is UMTS AKA as defined in 3GPP TS 33.102.
The explained AKA usual procedure is well adapted for providing secure authentication and sharing of key material between both the hosting terminal HT and the authentication server AS. However, in some specific circumstances, it is needed that the algorithm AKAAIg be processed in a different way within the personal token. For instance, under some specific circumstances, it is required that the derived keys Ik and Ck or part of them be regarded as sensitive data and therefore be prevented from being disclosed to the hosting terminal, i.e. that the derived keys Ik and Ck be kept inside the personal token instead of being delivered to the hosting terminal.
In these specific cases, a basic requirement for lots of situations is that the hosting terminal could not retrieve the derived keys using the standard AKA or any other procedure.
The aim of the invention is to provide a solution for avoiding the disclosure of the derived keys to the hosting terminal.
More generally some specific authentication procedure exist which are based on the usual AKA procedure but which differ in some aspects which may be of any kind. A same personal token may be subject to different reactions according to different possible AKA procedures encountered during its lifetime.
A second aim of the invention is to propose a way to efficiently signalize that a particular authentication procedure is required to the personal token.